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(54) Secure computing device 

(57) A secure computing system (1 GO) stores a pro- 
gram, preferably the real time operating system (210). 
that is enaypted with a private key. A txx)t ROM (135) 
on the same integrated circuit as the data processor 
and inaccessible from outside includes an initialization 
program and a public key corresponding to the private 
key. On initialization the boot ROM decrypts at least a 
verification portion of the program. On verificatton nor- 
mal operation is enabled. On non-verification, the sys- 
tem could be disabled, or that application program could 
be disabled. A diagnostic program is stored at predeter- 
mined non-relocatable physical address in memory. The 
program is made non-relocatable using a special table 
look-askle buffer (137) having a fixed virtual address 
register (611) and a conesponding fixed physical 
address register (641). The secure computing system 



prevents unauthorized use of compressed video data 
stored in a first-in-f irst-out menxKy buffer by encrypting 
the compressed vkJeo data stream using at least a part 
of the chip identity number as an encryption key (703). 
The data is recalled from memory (705) and decrypted 
(706) as needed for video decompression. The delxig- 
ger/emulator tool commonly employed in program 
development is protected by a private encryption key 
used to encrypt at least verification token for tiie pro- 
gram. Upon each initialization of the debugger/ emula- 
tor, the secure computer system decrypts the 
verification token employing public decryption key (805) 
to indicate whetiier the program is secure or non- 
secure. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001] The tecKnIcal field of this invention is secure s 
conputing systems, especially computer systems that 
may execute after manufacture field provided programs 
secured to prevent the user from unauthorized use of 
selected computer services. The computer system may 
also be functionally reprogrammable In a secure man- io 
ner. 

BACKGROUND OF THE INVENTION 

[0002] There are currently many methods to deliver is 
video programming to users of television besides over 
the air broadcast. Numerous sen^ice providers are 
available to supply this programming to television view- 
ers. Most of these service providers vend a hierarchy of 
services, Typically there is a basic service for a baste 20 
fee and additional services available for an additional 
fee. The basic services typically include the broadcast 
network programming, cable superstations, music and 
sports programming. These basic services are typically 
supported by advertizing. These basic programming 25 
services thus operate on the same economics as over 
the air broadcast television. The additional sendees typ- 
ically include the so called "premium" programming 
such as sports and movies. These premium program- 
ming sen/ices are typically not advertizer supported. 30 
These are perceived by the television user as higher 
value services and television users are willing to pay 
their service providers additional fees lor these serv- 
ices. The service provider passes much of this addi- 
tional fee to the content providers as their compensation 35 
tor supplying the programming. There may be one or 
several tiers of these premium services made available 
by the service providers. At the top of this programming 
hierarchy Is pay per view programming. Pay per view 
programming typically includes music concerts and 40 
sporting events perceived as time sensitive and highly 
valuable by the television users. Pay per view may also 
include video on demand, where the television user 
requests a particular movie be supplied. This hierarchy 
of service exists for all cunent alternative methods of 45 
program delivery including television cable, over the air 
microwave broadcast and direct satellite television. 
[0003] Reception of such alternative programming 
services has required an additional hardware appliance 
beyond the user provided television receiver since the so 
beginning of cable television. Initially this additional 
hardware appliance merely translated the frequency of 
the signal from the transmission frequency to a stand- 
ard frequency used in broadcast television. Such a 
standard frequency is receivable by the user provided ss 
television receiver. This additional hardware appliance 
is commonly know as a "set top box" in reference to its 
typical deployment on top of the television receiver. Cur- 



rent set top boxes harvjle the hierarchy of security pre- 
viously described. 

[0004] In the past these set top boxes have been fixed 
function machines. This means that tiie operational 
capabilities of the set top boxes were fixed upon menu* 
fecture and not subject to change once installed. A per- 
son intending to compromise the security of such a set 
top box would need substantial resources to reverse 
engineer the security protocol. Accordingly, such fixed 
function set top boxes are considered secure. The 
future proposals for set top boxes places tiie security 
assumption in jeopardy. The set top box currently envi- 
sioned for the future would be a more capable machine. 
These set top boxes are expected to enable plural home 
entertainment options such as the prior known vkieo 
programming options, viewing video programming 
stored on fixed media such as DVD disks. Internet 
browsing via a telephone or cable modem and playing 
video games downloaded via the modem or via a video 
data stream. Enabling tiie set top box to be pro- 
grammed after installation greatiy complicates security. 
H wouki be useful in the art to have a secure way to ena- 
t>le field reprogramming of set top boxes witiiout com- 
promising the hierarchy of vkieo programming security. 

SUMMARY OF THE INVENTION 

[0005] The present application discloses a secure 
computing system. A program, preferably the secure 
computing system real time operating system, is 
encrypted with a private key. The data processor 
includes a boot ROM on the same integrated circuit that 
is Inaccessible from outskie the integrated circuit The 
boot ROM includes tiie public key conesponding to the 
private key used to encrypt the program. On initializa- 
tion the boot ROM deaypts at least a verification por- 
tion of the program. This enables verification or non- 
verification of the security of the program. The boot 
ROM may store additional public keys for verification of 
application programs following verifk^ation of the real 
time operating system. Alternatively, tiiese additional 
public keys may be stored in the non-volatile memory. 
[0006] On verification of the security of the program, 
normal operation is enabled. There are several remedial 
actions tiiat can take place on non-verification. The sys- 
tem could be disabled, or in the case of non-verification 
of an application following verification of the real time 
operating system only tiiat application program couki be 
disabled. The system coukJ notify the system vendor of 
tiie security violation using the modem of the secure 
computing system. 

[0007] A diagnostic program can check the security of 
a program. The program is stored at predetermined 
physical address In memory Relocation of these physi- 
cal addresses where the program is stored is prevented. 
The diagnostic program is loaded and checks tiie pro- 
gram at tiie predetermined physical address against a 
standard. The diagnostic program then indicates ttiat 
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the program is verified as secure if it meets the starxjard 
or non-verified as secure if It does not meet the stand- 
ard. 

[0008] The program is made non-relocatable using a 
spedal Xatiie look-aside buffer. The table look-aside s 
buffer has a fixed virtual address register and a plurality 
of writable virtual address registers. Each of these vir- 
tual address registers has a comparator and a corre- 
sponding physical address register. The physical 
address register corresponding to the fixed virtual 
address register is also fixed. The fixed virtual address 
register and the fixed physical address register encom- 
pass the range of addresses where the program is 
stored. The fixed virtual address register and the fixed 
physical address register are preferably mask progranv 
mable in manufacture via a metal layer 
[0009] The fixed virtual address register and the fixed 
physical address register may be registers ostensibly 
writable via the Instruction set architecture. In this case, 
attempts to write to these registers do not change their 
contents. In addition, it is preferable that attempts to 
write to these registers produce no faults or exceptions. 
Alternatively, the fixed virtual address register and the 
fixed physical address register may not be accessible 
via the instruction set architecture. 
[001 0] The disclosed embodiment of the secure com- 
puting system prevents unauthorized use of conf)- 
pressed video data stored in a first-in-first-out memory 
buffer in a set top box. Current video compression tech- 
niques do not compress data uniformly For this reason 
a uniform compressed video data rate does not trans- 
late into a unifbnn decompressed video data rate. Typi- 
cal set top boxes employ off chip DRAM as a first-in- 
first-out (FIFO) buffer to prevent the decompression 
process from overflowing or underflowing. The memory 
bus traffic between the data processor and the portion 
of memory used as the FIFO buffer is subject to inter- 
ception and unauthorized use. 
[0011] The data processor is disposed on a single 
integrated circuit. This data processor includes a chip 
identity read only register storing a unique chip identity 
number. This unique chip identity number is fixed during 
manufacture by, for example, laser probing or selective 
activation of fuse or antifuse links in the chip klentity 
register. The data processor encrypts the compressed 
video data stream using at least a part of the chip iden- 
tity number as an encryption key. This encrypted data is 
stored in the menrK)ry area serving as the FIFO buffer. 
The data is recalled from menrK)ry as needed for vkileo 
decompression. The date processor then decrypts the 
recalled data employing at least a part of the chip iden- 
tity number as the decryption key 
[0012] Using this technique the compressed video 
data stream temporarily stored in compressed form in 
the FIFO buffer can only be read by the particular data ss 
processor having the unique chip identity number. Since 
the chip identity number is unique to that particular data 
processor the video data cannot be processed by 



another data processor, even another kientical set top 
box system without breaking the code. The encryption 
and decryption is transparent to the user requiring only 
a small additional processing capacity within the data 
processor. 

[0013] Another aspect of this invention concerns the 
security of a oonputer system when used with a debug- 
ger/emulator tool commonly employed in program 
development Without special procedures to limit the 
operatbn of the debugger/emulator tool, the security of 
the computer system wouU be subject to compromisa 
[0014] The disclosed enrtxxfiment of the secure com- 
puting system uses an encryption system employing a 
private encryption key and a public decryption key The 
private encryption key is used to encrypt at least a veri- 
fication token for the program. The public decryption key 
corresponding to the private encryption key is stored at 
the secure computing system. Upon each initialization 
of the debugger/emulator for the secure computing sys- 
tem a security screen is performed. This involved deter- 
mining if the program is secure program or a non- 
secure program. The secure computer system decrypts 
the verifk:ation token employing public decryption key 
This decrypted verification token Indicates the program 
as a secure program or a non-secure program. If the 
program is a secure program, then the debugger/ emu- 
lator is operated in a process nrxxle. The process mode 
permits the debugger/emulator access to the program 
while prohibiting access to at least one security feature 
of the secure computing system. If the program is a 
non-secure program, then the debugger/emulator is 
operated in a raw nrKXie. The raw mode permits the 
debugger/emulator to access all features of the secure 
computing system. 

[0015] A further security layer is used for operating 
system development Intended for the secure computing 
system. Each data processor includes a unique chip 
Klentity number stored in a read only chip identity regis- 
ter. If the program is a secure program, then the debug- 
ger/emulator reads the chip identity number. A certain 
subset of the chip klentity numbers and only this subset 
will permit the debugger/emulator to operate in tiie raw 
for a secure program. If the chip kientity number does 
not fall within this subset, then the debugger/emulator 
can only operate in the process nxxle. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] The present invention will now be further 
described by way of exanrple, with reference to the 
accompanying drawings in which: 

Rgure 1 is a bkx:k diagram of one embodiment of 
the disck)sed secure computing system; 
Rgure 2 is an example memory map of the boot 
read only menrx)ry of the digital media processor 
illustrated in Rgure 1 ; 

Rgure 3 is em example memory map of the non-vol- 
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atile memory of the set top box illustrated in Rgure 
1: 

Figure 4 is an example memory map of the read 
write memory illustrated in Rgure 1 ; 
Figure 5 is a flow chart of the initial operation 
Including the operating system verification of the 
digital media processor illustrated In Figure 1 ; 
Figure 6 is a flow chart of the process for verifica- 
tion of an application to the set top box illustrated in 
Figure 1; 

Figure 7 Is a flow chart of the process of verification 
of a downloaded application program; 
Figure 8 is a schematic diagram of a translation 
look aside buffer preventing virtual memory reloca- 
tion of a certain page of memory of the digital 
media processor of Rgure 1 ; 
Figure 9 is a flow chart of the process of encrypting 
and decrypting compressed video data temporarily 
stored in random access memory; and 
Rgure 10 is a flow chart of the process of wode 
selection in a hardware debugger/emulator. 

DETAILED DESCRIPTION OF PREFERRED EMBOD- 
IMENTS 

[001 7] The set top box of the future will enable home 
entertainment options such as the known video pro- 
gramming options, viewing video programming stored 
on fixed media such as digital video disks (DVD), Inter- 
net browsing via a telephone or cable modem and play- 
ing video games downloaded via the modem or via a 
video data stream. Such a variety of capability can only 
be provided by a fully programmable data processor 
which can receive and run downloaded programs. This 
opens up a host of security issues. Since much of the 
utility of the system depends on being able to download 
various applications, the possibility also exists f&r an 
unauthorized application being downloaded. Such an 
unauthorized application may be deliberately written to 
compromise the hierarchy of security. 
[001 8] Fully programmable set top boxes are vulnera- 
ble to three main types of attacks. An unauthorized 
application may interact with the operating system, pos- 
sibly bypassing security The set top box non-volatile 
memory may be replaced with modified resident appli- 
cations, but with the original operating system. The non- 
volatile memory may be replaced with a new operating 
system. The most important Item to protect is the oper- 
ating system. If tiie operating system Is compromised, 
an unautiiorized person can do almost anything, includ- 
ing disguising the fact that the operating system is com- 
promised. 

[001 9] Figure 1 illustrates in schematic form the parts 
of a versatile, progranvnable set top box system 100. 
Set top box system 1 00 is responsive to inputs from: tel- 
evision cable 101 ; direct satellite receiver front end 103, 
digital video disk (DVD) 105; an ordinary telephone line 
107; and infrared remote control 109. These Inputs are 



conventional and need not be more fully described 
here. Any interaction of these conventional inputs with 
the parts of the disclosed embodiment of the secure 
computing system will be more fully described below. 

5 [0020] The central part of set top b(» system 100 Is 
the set top box 110. Set top box 110 includes various 
Interfaces for the inputs Including: video analog-to-dig- 
ital converter 111 connected to the television cable 101, 
which may optionally include a cable modem; video 

10 analog-to-digital converter 1 13 connected to direct sat- 
ellite receiver front erxi 103; a DVD driver 115 capable 
of receiving and reading DVD 105; voice band nrKxJem 
117 connected to telephone line 107; and infrared 
receiver 119 capable of receiving the infrared signals 

IS from infrared remote control 109. 

[0021] Set top box 110 includes several output 
devices coupled to digital media processor 130. Video 
digital-to-analog converter 121 receives a video data 
stream from digital media processor 130 and supplies 

20 an corresponding video signal to television receiver 
151 . Typically the desired video data stream is modu- 
lated upon a carrier having a frequency which the televi- 
sion receiver 151 can normally receive. It is 
contemplated that video media processor 130 in coop- 

25 eration with video digital-to-analog converter 1 21 will be 
capable of producing a video signal in a plurality of for- 
mats. Upon set up of set top box system 100 the partic- 
ular format will be selected to con-espond to the 
capability of tiie particular television receiver 151 

30 employed. Audio digital-to-analog converter 123 
receives an audio data stream from digital media proc- 
essor 130 and supplies a base band audio signal to 
audio system 1 53. It is contemplated that this audio sig- 
nal may encompass plural audio channels (i.e. left and 

35 right channels for stereo). It is also contOTplated that 
any particular video source may include plural encoded 
audio data streams such as altemative languages, 
descriptive video or other separate audio programs 
(SAP). Note also tiiat the audio data stream will typically 

40 also be modulated on the same canrier as the video sig- 
nal for reception and demodulation by television 
receiver 151. 

[0022] The intelligent part of set top box 1 1 0 is digital 
media processor 130. Digital media processor 130 is 

45 preferably embodied in a single integrated circuit. Note 
tiiat in order for set top box 1 10 to be fully secure as 
intended, central proces^ng unit 131 and boot ROM 
135 must be located on the same Integrated circuit. Dig- 
ital media processor 130 includes central processing 

50 unit 131. Central processing unit 131 is illustrated 
generically and is not intended to limit the structure 
enployed. Central processing unit preferably includes 
data processing capability for control functions required 
fbr selection of operating mode, channel tuning, security 

55 functions and the like. Central processing unit preferably 
also includes digital signal processing capability for 
decompressing compressed video arxl audio signals, 
decrypting encrypted video signals, converting the 
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received video to the format of the user's television 
receiver, operating as a ''software* cable modem and 
voice band modem and demodulating the signal from 
infrared remote control 109. Central processing unit 131 
may include a microprocessor and a digital signal proc- 
essa, a single data processor capable of alt the neces- 
sary functions or a multiprocessor. The exact nature of 
central processing unit, except for details noted below, 
is not relevant to disclosure of the present application. 
[0023] Digital media processor 130 further includes 
chip identity register 133. Chip identity register 133 is a 
programmable readable register holding an identity 
number unique to the integrated circuit embodying dig- 
ital media processor 130. This identity number is prefer- 
ably implemented as taught in U.S. Patent Application 
No. 08/813,887 entitied Circuits, Systeim, and Methods 
for Uniquely Identifying a Microprocessor at the Instruc- 
tion Set Level and filed March 7, 1997. As described in 
this patent application, the unique identification code is 
formed in a read-only data register by laser probing fol- 
lowing Integrated circuit test. The unique chip identity 
number may be specified via selective blowing of fuse 
or antlfuse links or otiier techniques. This identity 
number permits a program to verify tiie exact Identity of 
the particular digital media processor 130 used in the 
set top box 110. 

[0024] Digital media processor 1 30 Includes boot read 
only memory (ROM) 135, Digital media processor 130 
is constructed so that central processing unit 131 
begins executing program instructions stored within 
boot ROM upon each initial application of electric 
power. An exemplary memory map of boot ROM 135 is 
illustrated in Figure 2. Those skilled in the art will realize 
that the exact order of storage of the various parts is not 
as important as the existence of the detailed data types. 
Boot ROM 135 includes self boot code 201. Self boot 
code 201 is the program instructions initially executed 
by central processing unit 131 upon each initial applica- 
tion of electric power to digital media processor 130. In 
addition the known processes for initializing computer 
systems, self boot code 201 also includes verification 
program code 202. Verification program code 202 will 
be further described below in conjunction with Figure 5. 
Boot ROM 135 also Includes a public signature keys. 
These public signature keys include real time operating 
system (RTOS) public signature key 203, first applica- 
tion public signature key 205, second application public 
signature key, to the fslth application public signature key 
207. These public signature keys are employed In verifi- 
cation of the authorization of programs in a manner that 
will be further described below. 
[0025] Digital media processor 1 30 also Includes table 
look-aside buffer (TLB) 137. Table look-aside buffer 137 
is employed to enhance security during virtual menmry 
operation in a manner further described below. 
[0026] Set top box 11 0 includes flash (electrically pro- 
grammable read only memory) EPROM 141 bi-direc- 
tionally coupled to digital media processor 130. Flash 



EPROM 141 serves as the non-volatile memory for set 
top box system 100. This is known as a non-volatile 
memory because it retains its contents when electric 
power is turned "OFF". Non-volatile menx>ry is needed 

5 for the real time operating system (RTOS) and for resi- 
dent applications. Figure 3 illustrates an exemplary 
memory map of flash EPROM 141. Flash EPROM 141 
includes the real time operating system (RTOS) 210. 
RTOS 210 includes program code enabling digital 

10 media processor 130 to receive and process various 
data streams as they are received, i.e. in "real" time. 
RTOS 210 also enables digital media processa 130 to 
respond to operator control via infrared remote control 
1 09 and Infrared receiver 1 1 9. RTOS 2 1 0 Includes a sig- 

15 nature portion 211 whose use will be further described 
below. Flash EPROM 141 also includes program code 
fbr the first resident application 220 witii its correspond- 
ing signature portion 221. Likewise, flash EPITOM 141 
includes program code for the second resident applica- 

20 tion 230 and its corresponding signature portion 231 
and program code fbr ottier resident applications to the 
Mtii resident application 240 and its corresponding sig- 
nature portion 241. Rash EPROM 141 optionally 
includes additional public keys including N + 1st public 

25 key 251 , N + 2nd public key 253 to N + Pth public key 
255. These additional public signature keys are similar 
to the N public signature keys stored in kXKrt ROM 135. 
Their use will be detailed below. 
[0027] Set top box 11 0 further includes dynamic ran- 

30 dom access menwry (DRAM) 143 bi-directionally cou- 
pled to digital media processor 130. DRAM 143 is a 
volatile memory that serves as readAvrite memory to 
temporarily store ti-ansient data during normal opera- 
tions. DRAM 143 Is preferably embodied by synchro- 

35 nous memory employing a RAMBUS interface. Rgure 4 
illustrates an exemplary memory map of DRAM 143. 
DRAM 143 stores the memory resident part 261 of the 
real time operating system. Depending upon the partic- 
ular status of set top box system 100 this memory rest- 

40 dent part 261 of ttie RTOS may differ as known in tiie 
art. DRAM 1 43 stores the memory resident parts 263 of 
tiie currentiy running application or applications. These 
applications may be resident applications stored in flash 
EPROM 141 or transient applications stored in other 

45 parts of DRAM 143. Depending upon the status of set 
top box system 100, there may be various applications 
running and their Immediately accessible parts will be 
stored in DRAM 143 fbr faster access than from flash 
EPROM 141. DRAM 143 also Stores transient data 265. 

so This transient data 265 includes temporary data used 
by tiie various applications as well as tiie current control 
status as controlled by tiie user via infrared remote con- 
trol 109 and infrared receiver 119. DRAM 143 stores the 
program code of various transient applications such as 

55 first transient application 271 , second transient applica- 
tion 273 to Qtti transient application 275. Transient 
applications are those loaded via cable modem 111. 
voice band modem 117 or DVD drive 115 that are 
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intended for use only during the cun-ent session of set 
top txsx system 100. These may include video games, 
Internet browsing and the like, These transient applica- 
tions are loaded into DRAM 143 each time they are 
used and then discarded. DRAM 143 also stores com- 
pressed video in a first-in-first-out (FIFO) buffer 280. 
Video data from television cable 101, direct satellite 
receiver front end 103 and DVD 105 will generally be 
transmitted in compressed form. TTiis saves transmis- 
sion bandwidth and storage space. One of the tasks of 
digital media processor 130 is to decompress the video 
data. Current vkJeo compression formats (such as 
MPEG2) and all contemplated future video compres- 
sion formats are non-linear. That is, the different por- 
tions of the video data stream are compressed to 
differing degrees. Thus a constant rate of received 
video data rep>resents varying amounts of videa Follow- 
ing decompression, digital media processor must sup- 
ply video data in a constant rate to be viewed, 
Compressed video FIFO buffer 270 is necessary to 
smooth out the variations in the rate of receipt This per- 
mits the decompression process to neither overflow with 
too much compressed data nor underflow with no com- 
pressed data ready for decompression. This is possible 
because the compressed video data stream represents 
a constant rate video data stream that is to be viewed, 
Thus the overall average compressed vkJeo data rate 
corresponds to the constant real time viewing rate. 
[0028] Figure 5 is a flow chart 300 of an exanr^le of 
digital media processor 130 operations controlled by 
boot ROM 135. Upon each initial application of electric 
power to set top box system 100, digital media proces- 
sor begins executing the program stored in a predeter- 
mined location within boot ROM 135. Those portions of 
this program within boot ROM 1 35 relevant to disclosure 
of the present application are illustrated in Figure 5. Pro- 
gram 300 first initialized digital media processor 130 
(processing block 301). This process would include 
clearing registers and caches, setting the initial operat- 
ing mode and the like, in a manner known in the art. Fol- 
lowing initialization of the processor, program 300 reads 
the signature portion 21 1 of RTOS 210 stored in flash 
EPROM 141 (ixocessing block 302). Program 300 next 
reads the RTOS public key 203 from boot ROM 135 
(processing block 303). Next program 300 verifies the 
signature portion 211 of RTOS 210 (processing block 
304). In accordance with the known art of public key 
encryption such as the RSA algorithm, signature por- 
tion 21 1 1s produced by operating upon all of RTOS 210 
with a secret private signature key. The original data of 
signature portion 21 1 is recovered by a reverse process 
employing RTOS public signature key 203 stored in boot 
ROM 135. This signature verification process takes into 
account what is know as a "trap door" function. H is a 
very difficult process to produce a particular signature 
portion knowing only the public key. A change of any 
portion of RTOS 210 is very likely to result in a change 
in the signature portion 211 in a manner tiiat cannot be 



predicted from only the RTOS public signature key 203. 
Thus it is possible to detect any change in RTOS 210 
employing the signature portion 21 1 . 
[0029] Following the verification, program 300 tests 

5 the verified signature portion to determine if RTOS 210 
supports secure applications (decision block 305). The 
preferred embodiment of the secure computing system 
of the present application contenplates that digital 
media processor 130 could be embodied in applications 

10 not requiring the security of set top boxes. In such appli- 
cations, the verified signature portion 21 1 indicates that 
the RTOS need not be secured. Note that even a non- 
secure RTOS must have its stub verified. Failure of tiie 
signature verification is fatal whether the RTOS is 

IS secure or non-secure. Program 300 bypasses other 
steps and starts RTOS 210 (processing block 310) if 
this signature portion 211 indicates a non-secure use. 
This will typically involve loading at least a portion of 
RTOS 210 into DRAM 143. It is anticipated that DRAM 

20 143 will allow much faster memory access tiian flash 
EPROM 141. Thus loading portions of RTOS 210 into 
DRAM 143 will enable faster operation. 
[0030] If the verified signature portion indicates that 
RTOS 210 is to support secure applications (decision 

25 block 305). then program 300 tests to determine if 
RTOS 210 can be verified as correct (decision block 
306). As descn'bed above, the trap door function of tiie 
private key signature with public key signature makes it 
a very difficult task to modify RTOS 21 0 without produc- 

30 ing an unpredictable modification of signature portion 
211. Thus the initial program stored in boot ROM 135 
will almost certainly be able to detect unauttiorized 
modification of RTOS 210. This verification of RTOS 
210 permits the vendor of set top box system 100 to be 

35 confident of the security of the system. 

[0031 ] If the verified signature portion is not verified as 
secure, tiien prograin 300 indicates that RTOS 210 is 
non-secure (processing block 307). Thereafter program 
300 takes remedial action (processing block 308). This 

40 remedial action can take many forms. At the nfx>st 
severe, this remedial action coukil be complete disable- 
ment of set top box 1 10. Shutting down media proces- 
sor 130 will disable set top box 110 since it is the 
Intelligence of set top box 1 10, In most secure applica- 

45 tions running a non-verified RTOS wouki be considered 
very dangerous and the only reasonable remedial 
action is disabling set top box 1 10. In a few cases a less 
severe remedial action may be appropriate. As a less 
severe remedial measure, digital media processor 130 

50 couki be programmed to no longer interact with vkieo 
data streams from tele/ision cable 101, direct satellite 
receiver front end 103 and/or DVD 105. This mode may 
permit running local only transient applications. The 
remedial action could include signaling the set top box 

55 vendor or service provkier of the security violation via 
cable modem 1 1 1 or voice band modem 1 1 7. The recip- 
ient of this notification coukJ then determine either auto- 
matically or manually how to deal witii the security 
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violation. One method of responding to such a notifica- 
tion of a security violation is to download via cable mode 
1 1 1 or voice band nxxiem 1 1 7 an authorized copy of the 
RTOS for storage in flash EPROM 143, overwriting the 
unauthorized copy. Another method is to download a 5 
diagnostic program which will verify and determine the 
extent of the security violation. At the least severe level 
most suitable for service providers who supply only 
advertiser supported program material, is to ignore the 
security violation and permit operation of the non- 10 
secure RTOS. 

[0032] If the verified signature portion is verified as 
secure, then program 300 indicates that RTOS 210 as 
verified (processing block 309). Thereafter program 300 
starts operation of RTOS 210 (processing block 310). is 
As described above this would typically involve copying 
at least portk)ns of RTOS 210 from flash EPROM 141 to 
DRAM 143. Following such a copying, program control 
wouW be transfen-ed to the RTOS copy in DRAM 143 
via a jump instruction. RTOS 210 then enables all the 20 
authorized functions of set top box system 100. 
[0033] The entire RTOS could be encrypted using the 
private key as an alternative to employing merely a sig- 
nature verification process. The steps illustrated in Fig- 
ure 5 would be similar except that the entire RTOS must 25 
be decrypted using the public key rather than just the 
signature portion. In this event, the decrypted RTOS 
would be copied to a operating portion of DRAM 143 
upon verification. Thereafter program control would be 
passed to this copy of the RTOS from the boot ROM 30 
program via a jump instruction. In this case a non-veri- 
fied RTOS even If copied into the same part of DRAM 
1 43 will not operate. An incorrect decryption of an unau- 
thorized RTOS 210 would likely result in an inoperable 
operating system. Thus the remedial action is this case ss 
disables set top box 1 10, Note the use of a private key 
to encrypt and a pOblk: key to decrypt is the reverse of 
the usual private key/lpublic key system. Currently, only 
the RSA system is known to permit this reverse use. 
[0034] Figure 6 is a flow chart 400 of an example of 40 
digital media processor 130 operations when called to 
load and run a resident application. Following the com- 
mand to start the resident application program 
(processing block 401). program 400 reads the corre- 
sponding signature portion of tiie resident application 45 
stored in flash EPROM 141 (processing block 402). Pro- 
gram 400 next reads the corresponding put)iic key from 
boot ROM 135 or flash EPROM 141 (processing block 
403). As noted above in the memory maps of boot ROM 
135 and flash EPROM 141 , the public keys for resident so 
application programs may be stored in boot ROM 135 or 
in flash EPROM 141. Alternatively, set top box 100 may 
be constructed so that the public keys for some resident 
applications are stored in boot ROM 135 and the public 
keys for the remaining reskient applications are stored ss 
in flash EPROM 141 . Next program 400 verifies the sig- 
nature portion of the resident application (processing 
block 404). This signature verification process is the 



same as previously described in conjunction with verifi- 
cation of RTOS 210. 

[0035] Following the verification, program 400 tests 
the verified signature portk)n to determine if the resident 
application supports security (decision block 405). K is 
contemplated that any reskient applk:ation that Interacts 
with program content received from television cable 
101. direct satellite receiver front end 103 or DVD 150 
will require security. Other reskient applications may 
require security at the optton of the application program 
vendor. Program 400 bypasses other steps, load the 
reskient application into DRAM 1 43 and starts the appli- 
cation program (processing block 410) if this signature 
portion indicates a non-secure use. 
[0036] If the verified signature portion indicates that 
the resident application is to support secure applica- 
tions (decision block 405). then program 400 tests to 
determine if the reskient application can be verified as 
correct (decision block 406). The trap door function of 
the private key encryption witii public key deayption 
makes it a very difficult task to modify the resident appli- 
cation program without producing an unpredictable 
modification of signature portion, thus enabling verifica- 
tion of the authorization of the resident application. 
[0037] If the signature portion is not verified as secure, 
then program 400 indicates that tiie resident application 
Is non-secure (processing block 407). Thereafter pro- 
gram 400 takes remedial action (processing block 408). 
This remedial action couki be any of tiie many forms 
described above. 

[0038] If tiie signature portion is verified as secure, 
tiien program 400 indicates tiiat the resident application 
as verified (processing block 409). Thereafter program 
400 starts the reskient application by transferring at 
least part of its program code to DRAM 143 and tians- 
ferring control via a jump instruction, It is contemplated 
ttiat reskient application programs will have access to 
less than all of the digital media processor functions 
accessible via RTOS 210. 

[0039] The entire reskient application could be 
enaypted using tiie private key as described above. 
The steps illustrated in Figure 6 would be similar except 
ttiat the entire resident application must be decrypted 
using the public key rather than just tiie signature por- 
tion. As previously described, using this technk^ue 
means that an unautiiorized program will probably 
crash and disable set top box 1 10. 
[0040] Figure 7 is a flow chart 500 of an example of 
verification of a downk)aded program. Following ttie 
command to start downloading an application program 
(processing block 501). program 500 downloads ttie 
application as stores it in DRAM 143 (processing block 
502). Then program 500 reads tiie caresponding sig- 
nature portion of the downloaded application stored in 
DRAM 143 (processing block 503). Program 500 next 
reads tiie corresponding public key from boot ROM 135 
or flash EPROM 141 (processing block 504). As noted 
above in ttie memory maps of boot ROM 135 and flash 
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EPROM 141, the public keys for resident application 
programs may be stored in either boot ROM 135 or in 
flash EPROM 141. Next program 500 runs signature 
verification on the downloaded application program 
(processing block 505). This signature verification proc- 
ess is the same as previously described in conjunction 
with verification of RTOS 210, A secure application pro- 
gram will have a signature portion that permits verif k^- 
tion of the entire downloaded application program. A 
non-secure application program will have a verifiable 
signature stub. 

[0041 ] Program 500 next tests to determine if the sig- 
nature or signature stub has been verified (decision 
block 506). If the signature or signature stub has not 
been verified as proper, then program 500 would indi- 
cate a security violation (processing block 507) and take 
remedial action (processing block 508). This remedial 
action could be any of the many forms described above. 
In addition, another possit)le remedial action in this 
instance is to make an further attempt to download this 
application. Thus program 500 couM loop back to 
processing block 502 to repeat the download. This 
remedial action woukf permit recovery if an authorized 
application was conijpted. such as by noise or the like, 
during download. If this option is used, it Is preferable to 
abort this loop if after a predetermined number of signa- 
ture verification failures. 

[0042] Following successful verification of the signa- 
ture or signature stub, program 500 tests tiie verified 
signature portion to determine if tiie downloaded appli- 
cation supports security (decision block 509). Program 
500 bypasses other steps, stores and runs the down- 
loaded application program (processing block 512), if 
this signature portion indicates a nonsecure use. Note 
that the downloaded application program may be 
loaded Into flash EPROM 141 if it is intended to be 
another resident application or Into DRAM 143 if It Is 
intended to be a transient application. 
[0043] If the verified signature portion indicates tiiat 
the downloaded application program supports secure 
applications (dedsion block 509), then program 500 
tests to detenrrine if ttie downloaded application can be 
verified as correct (decision block 511). The trap door 
function makes it a very difficult task to modify the 
downloaded application program without producing an 
unpredictable nxxilfication of signature portion, thus 
enabling verification of the authorization of the down- 
loaded application program. 

[0044] If tiie downloaded application program is not 
verified as correct (decision block 510), then program 
500 Indicates that the downloaded application is non- 
secure (processing block 507). Thereafter program 500 
takes remedial action (processing block 508). This 
remedial actton could be any of the many forms 
described above and may indude making a further 
attempt to download this application program. 
[0045] If the downloaded application is verified as cor- 
rect (decision block 510), then program 500 indicates 



the downloaded application is secure (processing block 

511) . Thereafter program 500 stores and runs the 
downloaded application program (processing block 

512) . As desalbed above, this storage will be in flash 
s EPROM 141 if the application is a resident application 

or in DRAM 143 if the application is a transient applica- 
tion. Program 500 starts the downloaded application 
program by transferring at least part of its program code 
to DRAM 143 and transferring control via a jump 
/o instruction. 

[0046] The entire downloaded application program 
could be encrypted using the private key as described 
above, The steps illusfa'ated In Rgure 7 woukJ be similar 
except that the entire downloaded application must be 
15 decrypted using the public key ratiier than just verifying 
the signature portion. As previously described, using 
this technique means that an unauthorized program will 
probably crash and disable set top box 1 10. 
[0047] This security technique relies upon the security 
20 of boot ROM 135. Since boot ROM 1 35 Is located on tiie 
sane integrated drcuit as ttie ottier parts of digital media 
processor 130 and ft is a read-only, ft is not subject to 
unautiiorlzed change. Therefore tiie verification function 
cannot be changed to verify a unauthorized RTOS. 
25 Many of the security functions will be available only to 
tiie RTOS based upon program privilege levels, Thus 
most security functions cannot be easily compromised. 
The private key used for encryption will only be known 
to the RTOS supplier, or only to the manufacturer of dig- 
so ital media processor 130. In addition the public key 
needed to verify the signature or to deaypt the RTOS is 
also In the boot ROM, This prevents substitution of 
another public key in an attempt to cause digital media 
processor 130 to verify an unauthorized RTOS. Addi- 
35 tionally, the resident applications are also secure. The 
private keys for resident applications can be known only 
by the application owner, or by the service provider who 
authorizes the application. 

[0048] The above private key^ublic key signature ver- 

40 ification system will protect against most security 
attacks. However, if the private key used to authenticate 
tiie RTOS is compromised, tiie security may be 
defeated by repladng the RTOS witii an unauttiorized 
RTOS whk:h will still look authentic. 

45 [0049] The simplest way to detect a modified RTOS 
woukJ be to check the resident RTOS against ttie 
authorized program. An application program, such as a 
diagnostic program, could read certain memory loca- 
tions in tiie RTOS to see if they contain ttie expected 

so values. This may not always reveal unauthorized substi- 
tution of anottier RTOS. Many complex data processors 
such as would be used to embody digftal media proces- 
sor 130 support virtual menxMry. In a virtual memory 
environment, ttie RTOS is quite capable of virtualising 

ss Itself. Thus the unauthorized RTOS woukJ intercept the 
confirming read attempts and retum the results that ttie 
diagnostic application expects from a copy of the 
authaized RTOS. However, ttiis unauthaized RTOS 
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would run instead of the original RIDS consequently 
compromising security. The present application pro- 
pose a technique which assures that an application can 
access a portion of memory directly without being inter- 
cepted and translated to a virtual address by the FOOS. 
[0050] Rgure 8 illustrates in block diagram form a 
translation look-aside buffer (TLB) 137 having a locked 
page in accordance with the teachings of the present 
application. Virtual memory applications translate a vir- 
tual address into a physical address. As Is known in the 
€Ul, TLB 137 receives a virtual address on bus 601 and 
supplies a conresponding physical address on bus 602. 
A predetermined number of most significant address 
bits of the virtual address are supplied to a plurality of 
comparators 621. 623. 625 and 627. The remaining 
least significant address bits of the virtual address on 
bus 601 are passed unchanged to the con'esponding 
bits of physical address on bus 620. Each comparator 
621 » 623, 625 and 627 has a corresponding virtual 
address register 611, 613. 615 and 617, respectively 
The comparators 621, 623, 625 and 627 determine if 
the predetermined number of most significant bits of the 
virtual address on bus 601 matches the contents of the 
respective registers 611. 613, 615 and 617. Each com- 
parator 621. 623. 625 and 627 supplied match indica- 
tion to multiplexer 650. Multiplexer 650 supplies the 
predetermined number of most significant bits from one 
of the physical address registers 641 . 643. 645 and 647. 
The physical address register selected by multiplexer 
650 corresponds to the comparator 621. 623. 625 or 
627 detecting a match. These most significant physical 
address bits selected by multiplexer 650 are supplied to 
the most significant bits of the physical address on bus 
602. Thus TLB 137 substitutes a predetermined 
number of bits of a physical address for the same 
number of bits of the virtual address. The number of 
possible substitutions enabled by the virtual address 
register and its corresponding comparator and physical 
address register is limited only by consklerations of 
operation code space to access the registers and the 
amount of space occupied by the TLB. In the prior art, 
virtual address registers 611. 613, 615 and 617 and 
physical address registers 641, 643, 645 and 647 are 
alterable via software. Thus the real time operating sys- 
tem has control of the mapping of virtual addresses to 
physical addresses. 

[0051] In the prefen'ed embodiments of the disclosed 
secure computing system one of the virtual address 
registers and the corresponding physical address regis- 
ter are fixed upon manufacture. In the preferred embod- 
iment this pair of registers are mask programmable at 
metal layers, permitting the locked page to be selected 
upon manufacture of the integrated circuit including TLB 
137 but unalterable following manufactura Figure 8 
illustrates a fixed virtual address register 61 1 and Its 
con'esponding fixed physical address register 641. In 
the preferred embodiment the virtual address stored In 
fixed virtual address register 621 equals the physical 



address stored in fixed physical address register 641 . In 
the prefen'ed embodiment, the critical code to be pro- 
tected from relocation will be stored in flash EPROM 
141 within the boundary of physical addresses covered 

5 by this virtual address register. Attempts to write to 
either fixed virtual address register 61 1 or fixed physical 
address register 641 will fail because these registers 
are fixed in hardware. Preferably there will be no faults 
or errors generated by an attempt to modify these regis- 

10 ters. Alternatively, neither the fixed virtual address reg- 
ister 61 1 nor the f ixed physical address register 641 are 
accessible via the instruction set architecture. Since the 
reason that fixed virtual address register 61 1 or fixed 
physical address register 641 are fixed is to prevent 

IS alteration, no access via the instruction set architecture 
would ever be required. 

[0052] A further feature of the disclosed embodiment 
of the present application is illustrated in Figure 8. Note 
that the match indication from comparator 621 is sup- 

20 plied directly to multiplexer 650. The match indication 
from other comparators form the noninverting input to 
respective AND gates 633. 635 and 637. Each of these 
AND gates 633, 635 and 637 receives tiie match indica- 
tion from comparator 621 on an inverting input. Thus a 

25 match indication from comparator 621 prevents supply 
of a match indication to multiplexer 650 from any other 
comparata. This prevents an unauthorized person from 
leaving the original RTOS in place to respond to security 
queries while attempting to run an unauthorized RTDS 

30 from a relocated part of memory. Any memory accesses 
to the physical memory addresses of virtual address 
register 611 and physical address register 641 cannot 
be relocated but are directed to the physical address of 
the original RTOS. 

35 [0053] With the disclosed embodiment of the present 
application an unauthorized attempt to relocate the 
RTOS may occur, but no actual address translation will 
take place. Thus if the original RTOS is always located 
in this memory area, a diagnostic program can read sig- 

40 nature locations with assurance tiiat the original physi- 
cal locations are being accessed. Thus tiie diagnostic 
program can determine if the RTOS is compromised, 
and take appropriate remedial action. This remedial 
action may include any of the remedial actions previ- 

45 ously described. 

[0054] The set top box 100 illustiBted in Rgure 1 
includes an additional potential security problem. 
DRAM 143 stores a video data stream that has been 
deaypted but not decompressed. This video data is 

50 Stored in compressed video FIFO buffer 280. It is possi- 
ble for an unautiiorized person to intercept this data as 
it is being transferred from digital media processor 130 
to DRAM 143 or as it is being transferred from DRAM 
143 and digital media processor 130. These data trans- 

55 fens will be interleaved with otiier data traffic between 
digital media processor 130 and DRAM 143. but it is 
feasible to separate the compressed video data. 
Because the video is compressed, a minimal anfx>unt of 
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memory would be required to store this data. Some 
content providers would like to prevent their video pro- 
gramming from such interception, Note that interception 
of the video data stream at this point would permit gen- 
eration of plural, identical and immediately viewable 5 
copies of the video. 

[0055] Rgure 9 illustrates in flow chart form a process 
preventing such unauthorized interception. Following 
reception of the video data stream (processing block 
701) digital media processa 130 decrypts the video 10 
data stream (processing block 702). This decryption Is 
subject to security procedures to ensure that the user is 
authorized to view this video data stream. Following this 
decryption of tiie source program, digital media proces- 
sor encrypts the video data stream again (processing is 
block 703). In this instance a relatively simple encryp- 
tion Is used, such as a simplified DES algorithm. The 
encryption key is preferably derived from the chip iden- 
tity number stored in chip identity register 133. This 
encrypted data is stored in compressed video FIFO 20 
buffer 280 (processing block 704). At the appropriate 
time, tiie video data is recalled from compressed video 
FIFO buffer 280 (processing block 705). The recalled 
data is decrypted using the encryption key derived from 
the chip identity number (706). Ihis data is then ready 2s 
for further processing (processing block 707). 
[0056] This technique has the advantage that the 
compressed video data stream temporarily stored in 
compressed video FIFO buffer 280 can only be read by 
the particular digital media processor 130. The chip 30 
identity number is unique to that particular digital media 
processor. The video data cannot be viewed by any 
other means, even another identical set top box system 
100 without breaking the code. This is believed ade- 
quate security by most content providers. Additionally, 35 
the encryption and decryption is transparent to the user. 
There only needs to be a small additional processing 
capacity available within digital media processor 130 
beyond the minimal requirement of the particular appli- 
cation. 40 
[0057] Another potential security problem is aeated 
by tiie hardware debugger/ emulator. The semiconduc- 
tor manufacturer of digital media processor 130 will 
generally also sell hardware debugger/emulator sys- 
tems to application program developers, including oper- 45 
ating system developers. Generally such hardware 
debugger/emulator systems by design have unlimited 
access to all of memory, including "prrvate" areas. Thus 
a hardware debugger/emulator system of the type 
known In the art would permit unauthorized breach of so 
the security of set top box system 100. 
[0058] The following modification to the hardware 
debugger/emulator system will guard against this 
potential security problem. The hardware debug- 
ger/emulator will operate in two modes, a process mode 55 
and a raw mode. In the process mode, the hardware 
debugger/emulator may only access a particular proc- 
ess or application program. All system access is permit- 



ted in the raw mode. 

[0059] Rgure 1 0 is a flow chart illustrating the process 
of selecting the mode at the hardware debugger/emula- 
tor. Upon start of the hardware debugger/ emulator 
(processing block 801). process 800 reads the signa- 
ture portion 211 of RTOS 210 stored in flash EPROM 
1 41 (processing block 802). Process 800 next reads the 
RTOS public key 203 from boot EPROM 135 (process- 
ing block 803). Next process 800 verifies the signature 
portion 211 of RTOS 210 (processing tkxk 804). Fol- 
lowing the verification, process 800 tests the verified 
signature portion to determine if RTOS 210 supports 
secure applications (decision block 805). As previously 
described, digital media processor 130 could be 
embodied in applications not requiring tiie security of 
set top boxes. In such applications, the verified signa- 
ture portion 211 indicates that the RTOS need not be 
secured. If this is the case, then process 800 bypasses 
other steps activates the hardware debugger/emulator 
in raw mode (processing block 806). 
[0060] If ttie RTOS supports secure applications 
(decision block 805). then process 800 checks to deter- 
mine if the chip Identity number stored In chip identity 
register 133 Is of the subset of possible chip identity 
numbers tiiat permit the raw mode for secure applica- 
tions (decision block 807). Some program developers, 
particulariy RTOS developers, will need access to the 
raw mode of the hardware debugger/emulator. The 
present application contemplates tiiat a bit or bits or 
some subset of the possit)le coding of tiie chip identity 
number will be reserved for hardware debugger/emula- 
tors supporting this use. TTius only a certain limited 
number of the digital media processors 130 will permit 
raw mode operation of tiie hardware debugger/emulator 
in environments supporting the security described 
above, The manufacturer of digital media processor 1 30 
will supply these particularly Identified chips only to 
trusted program developers. 
[0061 ] If tiie chip identity nurrt)er does not permit raw 
mode operation (decision block 807). process 800 
reads a token from tiie particular process or application 
program under development in tiie hardware debug- 
ger/emulator. Process 800 then determines if tills token 
Is verified as proper (decision block 809). This process 
could take place using the private key encryption and 
public key decryption described above, or another veri- 
fication procedure could be employed. If the token is not 
verified (decision block 809), then process 800 take 
appropriate remedial action (processing block 810). The 
various types of remedial action that could be taken 
have already been described. If the token is verified 
(dedsion block 809), tiien process 800 activates the 
hardware debugger/emulator in process mode 
(processing block 81 1). In the process mode, the hard- 
ware debugger/emulator may only access a particular 
process or application program corresponding to the 
verified token. 

[0062] This process satisfies all tiie requirements of 
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the users. Program developers who use digital media 
processor 130 is non-secure application will have com- 
plete access to the functions of the hardware debug- 
ger/emulator. Program developers who use digital 
media processor 130 is secure applications will have 
access limited. Most of those program developers will 
use the secure RTOS and have access only to their own 
programs as identified by the token encrypted with their 
corresponding private key RTOS developers will have 
complete system access but only to particular digital 
media processors having the proper chip identity num- 
bers. Thus the manufacturer of digital media processor 
130 can have the proper level of control in order protect 
the security of set top box systems 100. 
[0063] The exemplary embodiments of this patent 
application have been described in conjunction with a 
particular type system requiring computer security, i.e. 
the set top box. Those skilled in the art would realize 
that the use of these security techniques are not limited 
to this example. Particularly, almost any computer sys- 
tem requiring that some functions have a degree of 
security may employ these techniques. 

Claims 

1 . A secure computing system comprising: 



memory includes an application program for coop- 
erating with said real time operating system, said 
application program including a second verification 
code encrypted with a predetermined second pri- 
s vate key; 

saki read only menrK)ry further being arranged 
for storing a second public key con-esponding 
to said predetermined second private key, and 

10 sakJ inftiallzatlon program further Including 

instructions for causing sakl data processor to 
employ sakJ second public key to decrypt sakJ 
second verification code of said application 
program stored in said non-volatile memory, 

IS and to Indicate verification of security of saki 

application program or non-verification of secu- 
rity of said application program. 

4. The secure computing system of claim 1 , wherein 
20 said at least one program stored in said non-volatile 
memory includes a real time operating system for 
said secure computing system and a plurality of 
application programs for cooperating with saki real 
time operating system, each of sakl application pro* 
25 grams including a corresporxiing verification oo6e 
encrypted with a predetermined private key; 



a non-volatile memory for storing program 
code for at least one program, said program 
code including a verlfk;ation code encrypted 30 
with a predetermined private key; 
a data processor fbr data manipulatk)n under 
program control disposed on an integrated dr- 
cuit, saki data processor executing a program 
stored at a predetermined address upon each 3S 
initial application of electric power; 
a read only memory disposed on sakJ inte- 
grated circuit fbr storing a public key corre- 
sponding to said predetermined private key 
and for storing an initialization program stored 40 
beginning at said predetermined address, said 
initialization program including instructions for 
causing saki data processor to employ said 
public key to deaypt said verif'ration code of 
sad at least one program stored in said non- 45 
volatile memory, said initialisation program fur- 
ther including instructions for causing said data 
processor to indicate verification of security of 
saki program or non-veriftcation of security of 
saki program. so 

2. The secure computing system of daim 1. wherein 
saki at least one program stored in saki non-volatile 
memory comprises a real time operating system fbr 
saki secure computing system. ss 

3. The secure computing system of daim 2, wherein 
saki at least one program stored in saki non-volatile 



saki read only memory being arranged fbr stor- 
ing a public key corresponding to each of saki 
predetermined private keys, and said initializa- 
tion program further including instructions for 
causing saki data processor to employ saki 
corresponding public key to decrypt saki verifi- 
cation code of each of saki plurality of applica- 
tion programs stored in said non-volatile 
memory, and to indicate verification of security 
of each of said plurality of applk^tion programs 
or non-verification of security of each of saki 
application programs. 

5. The secure computing system of any of daims 1 to 
4. wherein said Initialization program stored in saki 
read only mevnory indudes instructions fbr causing 
said data processor to disable operation of saki 
program upon non-verifk:ation of security of scud 
program stored in saki non-volatile memory. 

6. A secure computing system comprising: 

a memory fbr storing data and/or instructions at 
corresponding addresses; 
an address generator for generating virtual 
addresses of a first predetermined number of 
bits fbr accessing data and/or instructions in 
saki memory; 

a table look-askle buffer connected to saki 
address generator having a fixed virtual 
address register of a second predetermined 
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number of bits less than said first predeter- 
mined number of bits. 

a plurality of writable virtual address regis- 
ters of said second predetermined number s 
of bits. 

a first comparator connected to said 
address generator and said fixed virtual 
address register for comparing the con- 
tents of said first fixed address register 10 
with said second predetermined number of 
bits of said virtual address and indicating a 
match, 

a plurality of second comparators, each 
connected to a con^esponding virtual is 
address register and said address genera- 
tor, each fa comparing the contents of 
said corresponding virtual address register 
with said second predetermined number of 
bits of said virtual address and indicating a 20 
match. 

a fixed physical address register of said 
second predetermined number of bits, 
a plurality of writable physical address reg- 
isters of said second predetermined 2s 
number of bits, and 

a multiplexer connected to said memory, 
said address generator, said first compara- 
tor, each of said second comparators, said 
fixed physical address register and each of 30 
said plurality of writable physical address 
registers, said multiplexer responsive to a 
match by one of said comparators to sub- 
stitute contents of a physical register corre- 
sponding to said matching corrparator for ss 
most significant bits of said virtual address 
and thereby form a physical address sup- 
plied to said memory for memory access. 

7. The secure computing system of claim 6. wherein: 40 

said multiplexer is responsive to an indication 
of a match by said first conparator to substitute 
the contents of said fixed physical register for 
most significant bits of said virtual address. 45 

8. The secure computing system of claim 6 or daim 7, 
wherein said fixed virtual address register and said 
fixed physical address register are mask program- 
mable in manufacture. so 

9. The secure computing system of any of claims 6 to 
8. wherein said plurality of writable virtual address 
registers and said plurality of writable physical 
address registers are writable upon execution of an ss 
instruction by said secure computing system; 

said fixed virtual address register and said 



fixed physical address register writable upon 
execution of an instruction by said secure com- 
puting system, an attenrpt to write to either said 
fixed virtual address register or said fixed phys- 
ical address register via said instruction being 
arranged to fail to alter contents of said register 
and to generate no enror message or fault 

10. A secure computing system comprising: 

a data processor deposed on a single inte- 
grated circuit, said data processor including a 
chip identity read only register for storing a 
unique chip identity number; 
a memory bi-directionally coupled to said data 
processor for storing data; 
said data processor being programmed to: 

(i) encrypt data employing at least a part of 
said chip identity number as an enayption 
key. 

(ii) store sakl encrypted data in sakl mem- 
ory, 

(iil)recall said stored data from said mem- 
ory, and 

(iv) decrypt said recalled data employing at 
least a part of saki chip klentity nuni>er as 
decryption key. 

1 1 . The secure computing system of claim 1 0, wherein: 

sakJ data comprises a stream of vkleo data. 

12. A mettiod of secure computing comprising the 
steps of: 

encrypting a verification token for a program 
with private key; 

storing a public key corresponding to said pri- 
vate key; 

upon each initialization of a debugger/emulator 
for a secure computing system determining if 
said program is secure program or a non- 
secure program. 

if said program is a non-secure program select- 
ing a first operating mode in said debug- 
ger/emulator permitting access to said program 
while prohibiting access to at least one security 
feature of the secure computing system, and 
if said program is a secure program selecting a 
second operating mode in said debugger/emu- 
lator permitting access to all features of the 
secure computing system. 

13. The method of secure computing of daim 12, fur- 
tiier comprising tiie steps of: 

storing a unique chip identity number on a data 
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processor withtn the secure computing system; 
if said program is a secure program testing to 
determine If said unique chip identity number of 
said data processor is within a predetermined 
subset of possible cNp identity numbers; s 
if said unique chip identity number of said data 
processor is within said predetermined sut)set 
of possible chip identity numbers selecting said 
second operating nrxxie in said debugger/emu- 
lator; and 10 
if said unique chip identity number of said data 
processor is not within said predetermined 
subset of possible chip identity numbers select- 
ing said first operating mode in said debug- 
ger/emulator. IS 

14. The method of secure computing of claim 12. fur- 
ther comprising the steps of: 
wherein said program is an operating system for a 
data processor of the secure computing system; 20 

encrypting wrtii a second private key at least a 
verification token of an application program; 
storing a second public key corresponding to 
said second private key; 25 
decrypting said application program employing 
said public key as a decryption key; 
indicating verification or non-verification of 
security of said decrypted application program; 
selecting said first operating mode in said 30 
debugger/emulator if said decrypted applica- 
tion program is verified as secure. 
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